Secure Shell (SSH) 프로토콜

2025-10-26, G25DR

1. 프로토콜의 기초와 암호학적 핵심

1.1 Secure Shell 개론

Secure Shell (SSH)은 현대 정보 기술 환경에서 원격 시스템 관리를 위한 핵심적인 프로토콜 스위트로서, 단순한 도구를 넘어 보안 통신의 근간을 이룬다. 이 섹션에서는 SSH의 근본적인 정체성을 확립하고, 안전하지 않은 레거시 프로토콜로부터의 필연적인 진화 과정을 추적하며, 그 계층적 아키텍처를 정의한다.

1.1.1 SSH의 정의: 비보안 네트워크상의 보안 채널

Secure Shell, 통상적으로 SSH는 안전하지 않은 네트워크를 통해 두 컴퓨터 간에 암호화된 보안 연결을 설정하기 위해 설계된 네트워크 프로토콜이다.1 인터넷과 같이 신뢰할 수 없는 네트워크 환경에서 데이터의 기밀성(confidentiality)과 무결성(integrity)을 보장하는 것을 핵심 목적으로 한다. 이를 통해 도청(eavesdropping), 연결 하이재킹(connection hijacking), 그리고 기타 네트워크 수준의 공격으로부터 통신을 보호한다.3

SSH는 클라이언트-서버 모델을 기반으로 동작한다. 로컬 머신에 설치된 SSH 클라이언트가 원격 서버에서 실행 중인 SSH 데몬(sshd)에 연결을 요청하는 방식으로 작동하며 5, 기본적으로 TCP 포트 22번을 사용한다.1 이 프로토콜은 인증, 암호화, 무결성 보호 기능을 통합적으로 제공하여 원격 로그인, 원격 명령어 실행, 파일 전송 등 다양한 작업을 안전하게 수행할 수 있는 기반을 마련한다.2

1.1.2 역사적 배경: 텔넷의 불안정성과 SSH의 탄생

SSH가 등장하기 이전, 텔넷(Telnet), rlogin, rsh와 같은 프로토콜이 원격 접속의 표준으로 사용되었다.7 이들 레거시 프로토콜의 치명적인 결함은 모든 데이터, 특히 사용자 이름과 비밀번호 같은 인증 정보를 암호화하지 않은 평문(plaintext) 형태로 전송한다는 점이었다.2

이러한 근본적인 취약점은 네트워크 스니핑(sniffing) 공격에 극도로 취약하게 만들었다. 공격자는 네트워크 트래픽을 가로채기만 하면 인증 정보와 전체 세션 내용을 손쉽게 탈취할 수 있었다.2 이 위험은 매우 심각하여, 해당 프로토콜을 통한 모든 통신은 사실상 외부에 완전히 노출된 것으로 간주되었다.1

이러한 보안 공백에 대한 직접적인 해결책으로 1995년 타투 윌뢰넨(Tatu Ylönen)에 의해 SSH가 개발되었다.1 SSH는 원격 세션의 모든 측면을 보호하기 위해 강력한 암호화 기법을 도입했으며, 이는 네트워크 프로토콜 설계의 패러다임을 근본적으로 바꾸는 계기가 되었다. 텔넷이 설계될 당시의 네트워크는 비교적 안전한 학술적 환경으로 간주되었고, 따라서 네트워크 경로 자체를 신뢰하는 “신뢰 기반 네트워크(trusted network)” 모델에 기반했다. 반면, 상업화되고 적대적인 환경으로 변모한 인터넷의 현실 속에서 탄생한 SSH는, 기본적으로 네트워크를 신뢰할 수 없다는 “제로 트러스트(zero-trust)” 혹은 “적대적 네트워크(hostile network)” 모델을 채택했다. 이는 보안이 네트워크 인프라가 아닌, 애플리케이션 스스로가 종단 간(end-to-end)으로 책임져야 한다는 현대적 보안 철학의 시초가 되었다. SSH는 빠르게 사실상의 표준(de facto standard)으로 자리 잡았고, 결과적으로 텔넷과 그 유사 프로토콜들을 보안 관리 분야에서 사실상 퇴출시켰다.3

다음 표는 텔넷과 SSH의 보안 특성을 직접적으로 비교하여 SSH가 왜 혁신적이고 필수적인 대체재였는지를 명확히 보여준다.

Table 1: 텔넷 vs. SSH 보안 특성 비교

1.1.3 SSH 프로토콜 스위트: 계층적 아키텍처

SSH는 단일 프로토콜이 아니라, 서로의 기능을 기반으로 구축된 세 개의 뚜렷한 계층으로 구성된 프로토콜 스위트(suite)이다.

1. 전송 계층 (Transport Layer, SSH-TRANS): 이 기본 계층은 초기 연결 설정, 서버 인증, 암호화 매개변수 협상, 그리고 데이터 채널의 암호화, 압축, 무결성 검사를 담당한다. 일반적으로 TCP/IP 위에서 동작하며, 전체 통신의 보안 기반을 확립한다.4

2. 인증 계층 (Authentication Layer, SSH-AUTH): 전송 계층 위에서 실행되며, 클라이언트를 서버에 인증하는 역할을 전담한다. 가장 대표적인 비밀번호 기반 인증과 공개키 기반 인증을 포함한 다양한 인증 방법을 지원한다.

3. 연결 계층 (Connection Layer, SSH-CONN): 이 계층은 단일 암호화 터널을 다수의 논리적 채널로 다중화(multiplexing)하는 기능을 관리한다. 이 채널들은 대화형 셸 세션, 원격 명령어 실행, 포트 포워딩(터널링), 그리고 X11 세션 등에 사용될 수 있다.

이러한 계층적 구조는 SSH의 유연성과 확장성을 보장하며, 각 계층이 명확하게 정의된 역할을 수행함으로써 프로토콜의 안정성과 보안성을 높이는 데 기여한다.

1.2 SSH의 암호학적 기반

SSH의 “Secure“라는 이름은 그 핵심을 이루는 암호 기술에서 비롯된다. SSH는 단일 암호화 방식에 의존하지 않고, 대칭키 암호화, 비대칭키 암호화, 그리고 해싱이라는 세 가지 종류의 암호학적 원리(cryptographic primitive)를 시너지 효과를 내도록 결합하여 기밀성, 인증, 무결성을 동시에 달성한다.

1.2.1 하이브리드 암호 모델

SSH는 대칭키 암호화, 비대칭키 암호화, 해싱 알고리즘을 복합적으로 사용하여 보안을 구현한다.11 이러한 하이브리드 접근 방식은 각 기술의 장점을 극대화하고 단점을 보완하여, 강력한 보안과 효율적인 성능을 모두 갖춘 시스템을 구축한다. 이는 암호학적 트레이드오프에 대한 깊은 이해를 바탕으로 한 실용적인 설계의 결과물이다. 만약 모든 통신을 계산 비용이 높은 비대칭키 암호화로 처리했다면 프로토콜은 실용적으로 사용하기 어려울 정도로 느렸을 것이고, 반대로 사전에 공유된 대칭키에만 의존했다면 안전한 키 분배 문제에 직면했을 것이다. SSH의 하이브리드 모델은 이 두 문제를 모두 해결하여, 보안과 성능이라는 두 마리 토끼를 모두 잡는 최적의 설계를 보여준다.

1.2.2 대칭키 암호화: 세션 데이터 스트림의 보안

• 개념: 대칭키 암호화는 암호화와 복호화에 동일한 하나의 공유 비밀키(“세션 키”)를 사용하는 방식이다.2 이 방식은 계산 속도가 매우 빨라, 활성화된 SSH 세션에서 지속적으로 발생하는 데이터 스트림을 암호화하는 데 이상적이다.15

• SSH에서의 역할: 초기 핸드셰이크 과정이 완료되면, 그 이후 클라이언트와 서버 간에 오가는 모든 통신(대화형 셸 입력, 파일 전송 데이터 등)은 협상된 대칭키 암호를 사용하여 암호화된다.13 이는 제3자가 데이터를 가로채더라도 그 내용을 해독할 수 없도록 하여 통신의 기밀성을 보장한다.2

• 알고리즘: SSH는 다양한 대칭키 암호(cipher)를 지원하며, 연결 설정 시 클라이언트와 서버는 상호 지원 가능한 가장 강력한 알고리즘을 협상하여 선택한다. 현대의 SSH 구현체들은 AES(Advanced Encryption Standard)의 다양한 운영 모드(예: aes256-ctr, aes256-gcm@openssh.com)와 ChaCha20-Poly1305(chacha20-poly1305@openssh.com) 같은 최신 알고리즘을 우선적으로 사용한다.13

1.2.3 비대칭키 암호화: 인증 및 키 교환

• 개념: 비대칭키 암호화, 또는 공개키 암호학은 수학적으로 연결된 한 쌍의 키, 즉 공개키(public key)와 개인키(private key)를 사용한다.3 공개키는 누구에게나 자유롭게 배포될 수 있으며 데이터를 암호화하거나 전자 서명을 검증하는 데 사용된다. 반면, 개인키는 소유자만이 비밀리에 보관하며, 암호화된 데이터를 복호화하거나 전자 서명을 생성하는 데 사용된다.14

• SSH에서의 역할: 비대칭키 암호화는 계산 비용이 높기 때문에 전체 세션을 암호화하는 데는 사용되지 않는다.13 대신, 다음과 같은 짧지만 매우 중요한 두 가지 핵심적인 목적을 위해 사용된다.

1. 서버 인증: 서버는 자신의 개인 호스트 키(private host key)를 사용하여 클라이언트에게 자신의 신원을 증명한다.

2. 클라이언트 인증: 공개키 인증 방식에서, 클라이언트는 자신의 개인키를 사용하여 서버에게 자신의 신원을 증명한다.11

3. 키 교환: 디피-헬만(Diffie-Hellman) 키 교환 과정에서 비대칭키 암호화 원리가 적용되어, 실제 세션 키를 네트워크상으로 전송하지 않고도 양측이 안전하게 동일한 대칭 세션 키를 생성하고 공유할 수 있게 한다.12

• 알고리즘: 널리 사용되는 알고리즘으로는 RSA, DSA, ECDSA(타원 곡선 디지털 서명 알고리즘), 그리고 EdDSA(에드워즈 곡선 디지털 서명 알고리즘)가 있다. 특히 ECDSA와 EdDSA(구체적으로는 Ed25519)는 더 짧은 키 길이로도 RSA와 동등하거나 더 강력한 보안을 제공하여 현대 시스템에서 선호된다.11

1.2.4 해싱과 HMAC: 데이터 무결성 보장

• 개념: 해싱 알고리즘은 임의의 길이의 입력 데이터를 받아 고정된 길이의 문자열(“해시”)을 출력하는 단방향 함수이다.14 즉, 해시 값으로부터 원본 데이터를 역산하는 것은 계산적으로 불가능하다.12

• SSH에서의 역할: SSH는 데이터 무결성을 보장하기 위해 HMAC(Hash-based Message Authentication Code)이라는 형태로 해싱을 사용한다.13

• 메커니즘: 전송되는 각 데이터 패킷에 대해, 대칭 세션 키, 패킷 순서 번호, 그리고 실제 메시지 내용을 조합하여 HMAC 값이 계산된다. 이 HMAC 값은 암호화된 메시지와 함께 전송된다. 수신 측은 동일한 정보로 HMAC 값을 다시 계산하여 수신된 값과 비교한다. 두 해시 값이 일치하면, 해당 데이터가 전송 중에 변경되지 않았음을 확신할 수 있다.12 이 메커니즘은 데이터 변조 공격을 효과적으로 방어한다.

2. 연결 생명주기와 인증

이 파트에서는 초기 TCP 핸드셰이크부터 완전한 암호화 채널이 구축되기까지의 SSH 연결 과정을 단계별로 상세히 분석한다. 이어서 두 가지 주요 사용자 인증 방식의 메커니즘과 보안적 함의를 심도 있게 비교한다.

2.1 SSH 핸드셰이크의 해부

SSH 핸드셰이크는 두 단계로 구성된다. 첫 번째 단계는 보안 전송 계층을 구축하는 것이고, 두 번째 단계는 사용자를 인증하는 것이다.13 이 과정에서 중요한 점은 클라이언트가 서버를 먼저 인증한 후에야 서버가 클라이언트를 인증한다는 점이다. 이 순서는 사용자의 민감한 인증 정보(비밀번호 등)가 위조된 악성 서버로 전송되는 것을 방지하는 핵심적인 보안 장치로, 중간자 공격(Man-in-the-Middle, MITM)을 원천적으로 차단하는 역할을 한다.

2.1.1 1단계: 보안 전송 계층 구축

• 1단계: 프로토콜 버전 협상: 연결의 가장 첫 단계에서 클라이언트와 서버는 서로가 지원하는 SSH 프로토콜 버전을 확인하기 위해 평문으로 된 배너(예: “SSH-2.0-OpenSSH_8.2p1”)를 교환한다.2 SSH 프로토콜 버전 1은 여러 보안 취약점이 발견되어 현재는 사용되지 않으며, 모든 현대 시스템은 SSH-2를 사용해야 한다.11

• 2단계: 알고리즘 협상 (Key Exchange Init): 다음으로 클라이언트와 서버는 각자 지원하는 암호화 알고리즘 목록을 교환한다. 이 목록에는 키 교환 방식, 서버 호스트 키 알고리즘, 대칭키 암호(클라이언트-서버, 서버-클라이언트 방향별), MAC(메시지 인증 코드) 알고리즘, 압축 알고리즘 등이 포함된다.2 양측은 클라이언트가 제시한 목록의 우선순위에 따라, 공통으로 지원하는 첫 번째 알고리즘을 각 기능별로 선택한다.13

• 3단계: 디피-헬만 키 교환: 협상된 키 교환 알고리즘(예: diffie-hellman-group-exchange-sha256)을 사용하여, 클라이언트와 서버는 공개된 매개변수들을 교환하고 이를 바탕으로 각자 독립적으로 동일한 공유 비밀(세션 키)을 계산해낸다. 이 방식의 핵심은 비밀키 자체가 네트워크를 통해 결코 전송되지 않는다는 점이다. 따라서 통신을 도청하더라도 세션 키를 알아낼 수 없다.2

• 4단계: 서버 호스트 인증: 이 단계는 중간자 공격을 방지하는 데 결정적인 역할을 한다. 서버는 자신의 공개 호스트 키(public host key)와, 이 키가 자신의 것임을 증명하는 서명(자신의 개인 호스트 키로 생성)을 클라이언트에게 전송한다. 클라이언트는 수신한 공개 호스트 키를 로컬 시스템의 ~/.ssh/known_hosts 파일에 저장된 키와 비교한다.

• 키 일치: 파일에 해당 서버의 키가 존재하고 수신된 키와 일치하면, 서버는 신뢰할 수 있는 것으로 인증된다.

• 첫 연결: 파일에 키가 없는 경우(해당 서버에 처음 접속하는 경우), 클라이언트는 사용자에게 수신된 키의 지문(fingerprint)을 보여주며 신뢰 여부를 묻고, 사용자가 수락하면 키를 known_hosts 파일에 추가한다.2

• 키 불일치: 파일에 키가 존재하지만 수신된 키와 다른 경우, 이는 중간자 공격의 징후일 수 있다. 클라이언트는 심각한 보안 경고를 출력하고 일반적으로 연결을 즉시 종료한다.18

2.1.2 2단계: 사용자 인증

암호화된 터널이 성공적으로 구축되면, 연결은 인증 계층으로 넘어간다.11 클라이언트는 서버가 허용하는 인증 방법 중 하나를 사용하여 로그인을 시도한다. 이 과정은 다음 섹션에서 상세히 다룬다.

2.2 사용자 인증 메커니즘

이 섹션에서는 가장 널리 사용되는 두 가지 SSH 인증 방식을 비교 분석하고, 왜 업계 표준이 공개키 인증을 더 안전한 모범 사례로 채택했는지 설명한다.

2.2.1 비밀번호 기반 인증

• 메커니즘: 사용자가 제공한 사용자 이름과 비밀번호를 클라이언트가 이미 구축된 암호화 채널을 통해 서버로 전송한다. 서버는 이 정보를 자신의 로컬 사용자 데이터베이스와 대조하여 유효성을 검증한다.5

• 장점: 사용자에게 직관적이고 구현이 간단하다.

• 단점:

• 무차별 대입 공격(brute-force attack) 및 사전 공격(dictionary attack)에 취약하다. 공격자는 자동화된 도구를 사용하여 수백만 개의 비밀번호 조합을 시도할 수 있다.19

• 사용자가 여러 시스템에 동일한 비밀번호를 재사용하는 나쁜 보안 습관을 유발할 수 있다.

• 피싱(phishing)이나 사회 공학적 기법을 통해 사용자로부터 비밀번호가 유출될 수 있다.19

• 비밀(비밀번호)이 서버로 전송되므로, 만약 서버가 침해당할 경우 비밀번호가 노출될 위험이 있다.19

2.2.2 공개키 인증

• 메커니즘: 이 방식은 사용자가 사전에 생성한 비대칭키 쌍(예: id_rsa와 id_rsa.pub)에 의존한다.3

1. 설정: 사용자는 자신의 공개키를 접속하려는 서버의 ~/.ssh/authorized_keys 파일에 미리 등록해 둔다.21 개인키는 클라이언트 머신에 안전하게 보관한다.5

2. 챌린지-응답(Challenge-Response): 클라이언트가 접속을 시도하면, 서버는 authorized_keys 파일에서 해당 사용자의 공개키를 찾는다. 서버는 임의의 챌린지 메시지를 생성한 뒤, 이 메시지를 사용자의 공개키로 암호화한다.6

3. 소유 증명: 서버는 암호화된 챌린지를 클라이언트에게 전송한다. 이 메시지는 오직 해당 공개키와 쌍을 이루는 개인키를 가진 클라이언트만이 해독할 수 있다.6

4. 검증: 클라이언트는 자신의 개인키로 챌린지를 복호화하고, 그 결과를 세션 ID와 같은 정보와 결합하여 해시 값을 생성한 뒤 서버로 다시 보낸다. 서버 역시 동일한 계산을 수행하여 클라이언트가 보낸 해시 값과 일치하는지 확인한다. 일치하면 인증이 성공적으로 완료된다.6

• 핵심 원리: 이 과정에서 개인키는 절대로 클라이언트 머신을 떠나지 않는다.19 클라이언트는 단지 개인키를 ’소유하고 있음’을 암호학적으로 증명할 뿐이다.

• 장점:

• 인간이 기억할 수 있는 비밀번호와 비교할 수 없을 정도로 복잡도가 높은 암호키를 사용하므로, 무차별 대입 공격에 대해 사실상 면역에 가깝다.19

• 비밀번호 피싱의 위험을 원천적으로 제거한다.

• 대화형 비밀번호 입력이 필요 없어 자동화된 스크립트나 시스템 간 통신에 매우 용이하다.27

• 비밀(개인키)이 네트워크를 통해 전송되지 않으므로 탈취 위험이 없다.19

• 단점:

• 초기 키 생성 및 서버 등록 과정이 필요하다.

• 만약 개인키가 암호구(passphrase)로 보호되지 않은 상태에서 유출되면, 공격자가 즉시 접근 권한을 획득하게 된다.19

다음 표는 관리자와 사용자가 두 인증 방식의 실질적인 보안 트레이드오프를 이해하는 데 도움이 되는 결정적인 가이드 역할을 한다.

Table 2: 비밀번호 인증 vs. 공개키 인증 비교

2.2.3 실용적인 키 관리

• 생성: ssh-keygen 명령어를 사용하여 키 쌍을 생성한다. -t (타입, 예: rsa, ed25519)와 -b (비트 수) 같은 옵션은 키의 보안 강도를 결정하는 데 중요하다.5

• 암호구(Passphrase): 개인키 자체를 클라이언트의 디스크에 저장할 때 암호화하기 위해 강력한 암호구를 설정하는 것이 강력히 권장된다. 이는 클라이언트 머신이 도난당하거나 해킹당했을 때 개인키를 보호하는 결정적인 추가 보안 계층을 제공한다.18

• SSH 에이전트: ssh-agent(Linux/macOS)나 Pageant(Windows/PuTTY)와 같은 도구는 복호화된 개인키를 메모리에 안전하게 캐시한다. 이를 통해 사용자는 세션당 한 번만 암호구를 입력하면 되므로, 보안을 저해하지 않으면서도 편의성을 크게 향상시킬 수 있다.31

• 배포: ssh-copy-id 명령어는 서버에 공개키를 설치하는 가장 권장되는 방법이다. 이 도구는 ~/.ssh 디렉토리와 authorized_keys 파일에 대한 올바른 권한을 자동으로 설정하여 보안 실수를 방지한다.5

3. 실용적 애플리케이션과 고급 활용 사례

이 파트에서는 이론에서 벗어나 관리자와 개발자가 일상적으로 사용하는 SSH의 주요 기능을 탐색한다. 원격 셸 접속, 보안 파일 전송(SCP와 SFTP의 상세 비교 포함), 그리고 SSH 터널링의 강력한 기능들을 다룬다.

3.1 SSH의 핵심 기능

3.1.1 대화형 원격 셸 접속

SSH의 가장 근본적이고 널리 사용되는 기능은 원격 머신에 마치 직접 앉아 있는 것처럼 명령줄 인터페이스(셸)를 획득하는 것이다.1 이는 서버, 네트워크 장비, 클라우드 인스턴스 등 다양한 인프라를 원격으로 관리하는 표준적인 방법이다.3

• 기본 구문: ssh [사용자명]@[호스트명 또는 IP 주소] 5

3.1.2 보안 파일 전송: SCP vs. SFTP

SSH는 암호화된 채널을 통해 파일을 안전하게 전송하기 위한 두 가지 주요 프로토콜을 제공한다. 두 프로토콜 모두 SSH 연결의 보안성을 그대로 활용하지만, 기능과 사용 방식에서 뚜렷한 차이를 보인다.

• SCP (Secure Copy Protocol):

• 개념: 레거시 rcp 명령어에 기반한 단순한 파일 전송 프로토콜이다.39 비대화형(non-interactive) 방식의 단일 파일 또는 디렉터리 복사 작업을 위해 설계되었다.37

• 사용법: scp [옵션][원본 경로][대상 경로] 형식으로 사용하며, 원본과 대상 경로는 로컬 또는 원격(사용자명@호스트:경로)으로 지정할 수 있다.41

• 장점: 문법이 간단하고 프로토콜 오버헤드가 적어 순수 파일 전송 속도가 일반적으로 더 빠르다.39

• 단점: 기능이 매우 제한적이다. 중단된 전송을 이어받거나, 원격 디렉터리 목록을 보거나, 원격 파일을 삭제 또는 이름 변경하는 등의 관리 작업을 수행할 수 없다.39 또한, 유닉스 기반 시스템에 더 의존적이어서 플랫폼 독립성이 다소 떨어진다.44

• SFTP (SSH File Transfer Protocol):

• 개념: SSH-2의 확장 기능으로 설계된 현대적이고 강력한 프로토콜이다. 이는 “FTP over SSH“가 아니라, 원격 파일 시스템에 대한 완전한 인터페이스를 제공하는 별개의 새로운 프로토콜이다.39

• 사용법: sftp 사용자명@호스트 명령어로 대화형 세션을 시작하여 get, put, ls, rm 등과 같은 FTP와 유사한 명령어를 사용하거나, FileZilla, WinSCP와 같은 GUI 파일 전송 클라이언트의 백엔드 프로토콜로 사용된다.37

• 장점: 기능이 풍부하여 대화형 세션, 전송 이어받기, 디렉터리 목록 조회, 원격 파일 관리(이름 변경, 삭제, 권한 변경) 등 광범위한 작업을 지원한다.39 플랫폼 독립성이 뛰어나다.44

• 단점: 다양한 기능을 지원하기 위한 프로토콜 오버헤드가 있어, 고지연 네트워크 환경에서 단일 파일을 전송할 때 SCP보다 약간 느릴 수 있다.39

다음 표는 SCP와 SFTP의 특징과 성능을 비교하여, 사용자가 특정 작업에 적합한 도구를 선택할 수 있는 명확한 기준을 제공한다.

Table 3: SCP vs. SFTP 기능 및 성능 비교

3.1.3 원격 명령어 실행

SSH는 완전한 대화형 셸 세션을 시작하지 않고도 원격 서버에서 단일 명령어를 실행하고 그 결과를 로컬 터미널로 받아볼 수 있는 기능을 제공한다. 이는 스크립팅과 자동화 작업에 매우 유용하다.6

• 기본 구문: ssh 사용자명@호스트 '실행할 명령어' 5

3.2 SSH 터널링(포트 포워딩) 마스터하기

SSH 터널링은 임의의 TCP 트래픽을 안전하게 전달할 수 있게 해주는 SSH의 가장 강력하고 다재다능한 기능 중 하나이다. 이 기능은 방화벽을 우회하고, 비보안 프로토콜을 암호화하며, 내부 네트워크 서비스에 안전하게 접근하는 등 다양한 용도로 활용된다. 그러나 이러한 강력한 기능은 양날의 검과 같다. 합법적인 관리 목적으로 매우 유용하지만, 동시에 공격자가 보안 경계를 우회하여 데이터를 유출하거나 내부 네트워크에 백도어를 생성하는 데 악용될 수 있는 심각한 보안 위험을 내포하고 있다. SSH 터널링 트래픽은 암호화되어 있어 대부분의 네트워크 모니터링 및 필터링 솔루션이 그 내용을 검사할 수 없기 때문이다.47 따라서 관리자는 터널링 사용법뿐만 아니라, sshd_config의 AllowTcpForwarding 지시어를 통해 이를 통제하고 무단 사용을 감시하는 방법도 숙지해야 한다.

3.2.1 로컬 포트 포워딩 (-L)

• 개념: 로컬(클라이언트) 머신의 특정 포트로 들어오는 트래픽을 SSH 터널을 통해 원격(SSH 서버) 머신이 접근할 수 있는 최종 목적지 서버로 전달하는 방식이다.6

• 사용 사례: 외부 인터넷에 노출되지 않은 내부 네트워크의 서비스(예: 데이터베이스, 내부 관리용 웹 애플리케이션)에 안전하게 접근하고자 할 때 사용된다. 클라이언트는 자신의 localhost:[로컬 포트]에 접속하지만, 실제 트래픽은 암호화된 터널을 거쳐 [목적지 호스트]:[목적지 포트]로 전달된다.49

• 기본 구문: ssh -L [로컬 포트]:[목적지 호스트]:[목적지 포트][사용자명]@ 49

3.2.2 원격 포트 포워딩 (-R)

• 개념: 로컬 포트 포워딩의 반대 개념으로, 원격(SSH 서버) 머신의 특정 포트로 들어오는 트래픽을 SSH 터널을 통해 로컬(클라이언트) 네트워크에 있는 목적지 서버로 전달하는 방식이다.6

• 사용 사례: 방화벽 뒤에 있는 로컬 머신에서 실행 중인 서비스(예: 개발 중인 웹 서버)를 외부에서 접근할 수 있도록 공개적으로 접근 가능한 SSH 서버를 통해 노출시킬 때 유용하다. 로컬 네트워크의 복잡한 방화벽 규칙을 변경할 필요 없이 임시적인 외부 접근 경로를 만들 수 있다.49

• 기본 구문: ssh -R [원격 포트]:[목적지 호스트]:[목적지 포트][사용자명]@ 38

3.2.3 동적 포트 포워딩 (-D)

• 개념: 로컬(클라이언트) 머신에 SOCKS 프록시 서버를 생성하는 방식이다. 이 프록시를 사용하도록 설정된 애플리케이션(예: 웹 브라우저)의 모든 트래픽은 SSH 터널을 통해 원격 서버로 전달되며, 모든 요청은 원격 서버에서 시작된 것처럼 보이게 된다.49

• 사용 사례: 특정 목적지 호스트와 포트에 묶이지 않고, 원격 서버의 네트워크를 통해 자유롭게 웹 브라우징을 하거나 다른 네트워크 애플리케이션을 사용하고 싶을 때 유용하다. 이는 로컬 포트 포워딩보다 훨씬 유연한 터널링 방법을 제공한다.49

• 기본 구문: ssh -D [로컬 포트][사용자명]@

3.3 주요 플랫폼별 SSH 클라이언트 사용법

이 섹션에서는 가장 일반적인 운영 체제 환경에서 SSH 클라이언트를 사용하는 실용적인 명령줄 예제를 제공하며, Windows 환경에서 널리 사용되는 GUI 클라이언트인 PuTTY에 대해서도 다룬다.

3.3.1 Linux 및 macOS (OpenSSH)

거의 모든 Linux 배포판과 macOS 시스템에는 OpenSSH 클라이언트가 기본적으로 설치되어 있다.37 터미널 애플리케이션을 통해 즉시 사용할 수 있다.

• 원격 접속: ssh user@host 45

• 파일 전송 (SCP): scp /local/path/to/file user@host:/remote/path 43

• 파일 전송 (SFTP): sftp user@host 명령어로 대화형 세션을 시작한 후, put과 get 같은 내부 명령어를 사용한다.46

3.3.2 Windows (PowerShell 및 OpenSSH)

최신 버전의 Windows 10 및 11에는 PowerShell이나 명령 프롬프트에서 직접 사용할 수 있는 네이티브 OpenSSH 클라이언트가 포함되어 있다.5

ssh, scp, sftp 명령어의 구문은 Linux/macOS와 거의 동일하지만, Windows 파일 경로를 다룰 때는 공백이 포함된 경로를 큰따옴표로 묶는 등의 주의가 필요하다.42 또한, Posh-SSH와 같은 PowerShell 모듈을 사용하면 고급 SFTP 작업을 스크립트로 자동화할 수 있다.57

3.3.3 GUI 클라이언트: Windows의 PuTTY

PuTTY는 Windows 환경에서 가장 인기 있는 무료 오픈소스 SSH 클라이언트이다. 그래픽 인터페이스를 통해 세션 설정을 편리하게 관리할 수 있으며, 다음과 같은 여러 구성 요소로 이루어진 스위트를 제공한다.

• PuTTY: 핵심 SSH 및 텔넷 클라이언트 프로그램.

• PuTTYgen: RSA, DSA 등의 키 쌍을 생성하는 유틸리티.23

• Pageant: 개인키를 메모리에 로드하여 인증을 대행하는 SSH 인증 에이전트.31

• PSCP: 명령줄에서 사용하는 비대화형 보안 파일 복사(SCP) 도구.60

• PSFTP: 명령줄에서 사용하는 대화형 SFTP 클라이언트. 표준 ftp 클라이언트와 유사한 대화형 프롬프트를 제공하여, 단순 파일 전송만 가능한 PSCP보다 훨씬 복잡한 파일 관리 작업을 수행할 수 있다.40

4. 보안 강화 및 모범 사례

이 마지막 파트는 시스템 관리자를 위한 SSH 서버 보안 강화 종합 가이드이다. 핵심적인 sshd_config 설정 지침, Fail2Ban과 같은 능동적 방어 메커니즘을 다루고, 모범 사례 체크리스트로 마무리한다. 진정으로 견고한 SSH 보안 태세는 정적인 설정에 그치지 않고, 예방적 강화(sshd_config), 반응적 방어(Fail2Ban), 그리고 강력하고 확장 가능한 인증(공개키 또는 인증서)을 결합한 동적이고 다층적인 시스템으로 구축되어야 한다.

4.1 SSH 서버 보안 설정 (sshd_config)

OpenSSH 서버의 주 설정 파일은 /etc/ssh/sshd_config이다. 이 파일을 수정하는 것은 SSH 보안 강화의 가장 중요하고 첫 번째 단계이다. 설정 변경 후에는 반드시 sudo systemctl reload sshd와 같은 명령어로 서비스를 재시작하거나 설정을 다시 불러와야 변경 사항이 적용된다.5

4.1.1 인증 강화

• 비밀번호 인증 비활성화: 이는 무차별 대입 공격을 막는 가장 효과적인 단일 조치이다. 공개키 인증 사용을 강제함으로써 공격의 성공 가능성을 극적으로 낮춘다.

• PasswordAuthentication no 5

• 루트 로그인 비활성화: 관리자(root) 계정으로의 직접적인 원격 로그인을 금지하고, 일반 사용자로 로그인한 뒤 sudo를 통해 권한을 상승시키도록 강제한다. 이는 공격 표면을 줄이고 모든 관리 작업에 대한 추적성을 높인다.

• PermitRootLogin no 5

• 로그인 시도 횟수 제한: 연결당 인증 시도 횟수를 줄여 무차별 대입 공격의 효율을 떨어뜨린다.

• MaxAuthTries 3 17

4.1.2 프로토콜 및 네트워크 설정

• SSH 프로토콜 2만 사용: 알려진 취약점이 있는 구식 프로토콜 1의 사용을 완전히 배제한다.

• Protocol 2 17

• 기본 포트 변경: 기본 포트 22번을 비표준적인 높은 번호의 포트로 변경하는 것은 “보안을 통한 은닉(security through obscurity)“의 한 형태로, 완벽한 보안 대책은 아니지만 자동화된 스캔 공격과 로그 노이즈를 큰 폭으로 줄일 수 있다.

• Port 2222 (예시).5 포트 변경 시 방화벽 규칙도 함께 수정해야 한다.70

• 사용자/그룹 접근 제한: SSH 접근을 허용할 사용자와 그룹을 명시적으로 지정하여, 인가된 인원만 시스템에 접근할 수 있도록 제한한다.

• AllowUsers user1 user2 또는 AllowGroups sshusers 66

4.1.3 세션 및 포워딩 제어

• 타임아웃 설정: 유휴 세션과 로그인 유예 시간을 설정하여 불필요한 연결을 자동으로 종료시킨다.

• LoginGraceTime 30s 17

• ClientAliveInterval 300, ClientAliveCountMax 2 25

• 불필요한 포워딩 비활성화: X11 포워딩이나 TCP 포워딩 기능이 필요하지 않다면 비활성화하여 공격 표면을 최소화한다. 이는 앞서 언급한 터널링의 보안 위험을 통제하는 데 중요하다.

• X11Forwarding no 25

• AllowTcpForwarding no 49

다음 표는 관리자가 즉시 적용할 수 있는 실용적인 체크리스트 역할을 하며, 각 설정 지시어가 어떤 보안 원칙이나 위협 모델과 연결되는지를 명확히 보여준다.

Table 4: 필수 sshd_config 보안 설정 지시어

4.2 능동적 방어 메커니즘

정적인 설정을 넘어, 실시간으로 위협에 대응하는 능동적인 방어 도구는 보안을 한층 더 강화한다.

4.2.1 Fail2Ban을 이용한 무차별 대입 공격 완화

• 개념: Fail2Ban은 /var/log/auth.log와 같은 시스템 로그 파일을 실시간으로 감시하여 반복적인 로그인 실패와 같은 악의적인 패턴을 탐지하는 침입 방지 소프트웨어 프레임워크이다.66

• 메커니즘: 설정된 임계값(예: 10분 내 5회 로그인 실패)을 초과하는 IP 주소를 발견하면, Fail2Ban은 자동으로 방화벽(iptables 또는 firewalld) 규칙을 수정하여 해당 IP 주소로부터의 모든 연결을 일정 시간 또는 영구적으로 차단한다.70

• 설정: 일반적으로 기본 설정을 덮어쓰기 위해 jail.local 파일을 생성하여 설정한다. 핵심 설정값으로는 차단 시간(bantime), 감지 시간(findtime), 최대 시도 횟수(maxretry)가 있으며, SSH 포트를 변경했다면 해당 포트 번호를 정확히 지정해주어야 한다.70

4.2.2 고급 보안 조치

• 2단계 인증 (2FA): PAM(Pluggable Authentication Modules)과 Google Authenticator 등을 연동하여 2단계 인증을 구현할 수 있다. 이는 사용자가 가진 것(개인키)과 아는 것(비밀번호) 또는 소유한 것(TOTP 코드)을 모두 요구하여, 단일 인증 요소가 탈취되더라도 보안을 유지하는 강력한 추가 보호 계층을 제공한다.

• SSH 인증서: 대규모 인프라 환경에서는 개별 서버의 authorized_keys 파일을 일일이 관리하는 대신, 내부적으로 신뢰하는 SSH 인증 기관(Certificate Authority, CA)을 구축하는 것이 훨씬 확장성 있고 안전하다. 사용자와 호스트는 이 CA가 서명한 단기 유효 기간의 인증서를 발급받아 인증함으로써, 키 관리의 복잡성을 크게 줄이고 중앙에서 접근 제어를 용이하게 할 수 있다.

4.3 결론 및 권장 사항

이 보고서는 SSH 프로토콜의 역사적 배경, 암호학적 구조, 핵심 기능, 그리고 보안 강화 방안에 대해 포괄적으로 분석했다. 분석을 종합하여 관리자와 사용자를 위한 핵심 권장 사항을 제시하고, 보안 원격 접속의 미래를 조망한다.

4.3.1 종합 모범 사례 체크리스트

서버 관리자용:

1. 인증 강화: sshd_config 파일에서 PasswordAuthentication no와 PermitRootLogin no를 설정하여 비밀번호 및 루트 로그인을 비활성화하고, 오직 공개키 인증만 허용하라.

2. 접근 제어: AllowUsers 또는 AllowGroups 지시어를 사용하여 인가된 사용자 및 그룹만 SSH 접속을 허용하라.

3. 포트 변경: 기본 포트 22번을 비표준 포트로 변경하여 자동화된 공격을 회피하라.

4. 능동적 방어: Fail2Ban을 설치하고 설정하여 반복적인 로그인 실패 IP를 자동으로 차단하라.

5. 프로토콜 및 암호화: 오직 Protocol 2만 사용하고, 최신 암호화 알고리즘(예: Ed25519, AES-GCM, ChaCha20-Poly1305)을 사용하도록 서버를 설정하라.

6. 감사 및 로깅: SSH 관련 로그를 정기적으로 검토하여 비정상적인 활동을 감시하라.

7. 최신 상태 유지: OpenSSH 서버 소프트웨어를 항상 최신 버전으로 업데이트하여 알려진 취약점을 패치하라.

사용자용:

1. 강력한 키 사용: ssh-keygen을 사용하여 최소 4096비트 RSA 키 또는 Ed25519 키를 생성하라.

2. 개인키 보호: 생성된 개인키에 강력하고 긴 암호구(passphrase)를 설정하여 로컬 시스템이 침해당했을 경우를 대비하라.

3. SSH 에이전트 활용: ssh-agent나 Pageant를 사용하여 암호구를 한 번만 입력하고 편리하게 키를 사용하라.

4. known_hosts 파일 관리: 처음 접속하는 서버의 호스트 키 지문을 신뢰할 수 있는 경로를 통해 확인하고, 호스트 키 불일치 경고를 절대 무시하지 마라.

4.3.2 미래 전망: 양자내성암호와 SSH의 진화

현재 SSH의 보안을 책임지는 RSA, ECDSA와 같은 공개키 암호 알고리즘은 대규모 양자 컴퓨터의 등장으로 위협받을 수 있다. 양자 컴퓨터는 현재의 컴퓨터로는 해결하기 어려운 소인수분해나 이산 로그 문제를 효율적으로 풀 수 있어, 기존 암호 체계를 무력화할 가능성이 있다.

이러한 미래의 위협에 대비하여, 암호학계는 양자 컴퓨터로도 해독하기 어려운 양자내성암호(Post-Quantum Cryptography, PQC) 알고리즘을 활발히 연구하고 표준화하고 있다. 향후 SSH 프로토콜은 이러한 새로운 PQC 알고리즘을 키 교환 및 디지털 서명 메커니즘에 통합하는 방향으로 진화할 것이다. 관리자와 개발자는 이러한 기술 동향을 주시하며, 미래의 보안 패러다임 전환에 대비해야 할 것이다. SSH는 과거 텔넷의 보안 문제를 해결하며 등장했듯이, 미래의 양자 컴퓨팅 시대에도 안전한 원격 접속의 표준으로 남기 위해 끊임없이 발전해 나갈 것이다.

5. 참고 자료

1. Secure Shell - 나무위키, https://namu.wiki/w/Secure%20Shell
2. SSH프로토콜 원리 - 악분의 블로그 - 티스토리, https://malwareanalysis.tistory.com/755
3. SSH | 보안 셸 프로토콜 정의 - Cloudflare, https://www.cloudflare.com/ko-kr/learning/access-management/what-is-ssh/
4. What is SSH? | Secure Shell (SSH) protocol - Cloudflare, https://www.cloudflare.com/learning/access-management/what-is-ssh/
5. How to Use SSH to Connect to a Remote Server (Step-by-Step Guide) | DigitalOcean, https://www.digitalocean.com/community/tutorials/how-to-use-ssh-to-connect-to-a-remote-server
6. SSH Tutorial (Linux) - the Centre for Astronomy of Heidelberg University, https://zah.uni-heidelberg.de/it-guide/ssh-tutorial-linux
7. 시큐어 셸 - 위키백과, 우리 모두의 백과사전, https://ko.wikipedia.org/wiki/%EC%8B%9C%ED%81%90%EC%96%B4_%EC%85%B8
8. SSH란 무엇일까? - JS - 티스토리, https://seunghyunson.tistory.com/4
9. Telnet vs SSH (ssh를 사용해야 하는 이유) - 치킨맛코드, https://chicode.tistory.com/129
10. SSH, Telnet 프로토콜 비교 - 우리네 장, https://qpmi1zm29.tistory.com/8
11. Comparing SSH Keys - RSA, DSA, ECDSA, or EdDSA? - Teleport, https://goteleport.com/blog/comparing-ssh-keys/
12. What Is SSH: Understanding Encryption, Ports and Connection - Hostinger, https://www.hostinger.com/my/tutorials/ssh-tutorial-how-does-ssh-work
13. Understanding the SSH Encryption and Connection Process …, https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process
14. Understanding Encryption – Symmetric, Asymmetric, & Hashing - Atomic Spin, https://spin.atomicobject.com/encryption-symmetric-asymmetric-hashing/
15. What is Asymmetric Encryption? - IBM, https://www.ibm.com/think/topics/asymmetric-encryption
16. Public-key cryptography - Wikipedia, https://en.wikipedia.org/wiki/Public-key_cryptography
17. WEBDIR :: [CentOS] SSH 설정 - /etc/ssh/sshd_config - 티스토리, https://webdir.tistory.com/119
18. Connecting to GitHub with SSH, https://docs.github.com/en/authentication/connecting-to-github-with-ssh
19. SSH 공개 키 인증이 더 안전하다고 여겨지는 이유는 뭐임? : r … - Reddit, https://www.reddit.com/r/linuxadmin/comments/4uzf96/why_is_ssh_public_key_auth_considered_more_secure/?tl=ko
20. SSH란? - 이동건의 이유있는 코드 - 티스토리, https://baked-corn.tistory.com/52
21. 공개키 인증으로 SSH 접속하고 그 원리를 알아보자!, https://cms02.tistory.com/8
22. ssh key 발급 및 등록 (윈도우) - Jongya’s blog, https://whdrns2013.github.io/network/20240214_002_ssh_key/
23. SSH 접속 설정 방법: RSA 공개키 기반 로그인 완전 정리, https://somaz.tistory.com/24
24. ssh 서버 접속을 위한 키생성 및 설정 과정, https://stevenjsmin.tistory.com/210
25. SSH로 원격 서버 안전하게 접속 관리하기 :: 수서곤충의 세계, https://chinensis.tistory.com/entry/SSH%EB%A1%9C-%EC%9B%90%EA%B2%A9-%EC%84%9C%EB%B2%84-%EC%95%88%EC%A0%84%ED%95%98%EA%B2%8C-%EC%A0%91%EC%86%8D-%EA%B4%80%EB%A6%AC%ED%95%98%EA%B8%B0
26. [SSH] SSH의 key based authentication에 대하여 (공개키 암호화에 대한 이해), https://etloveguitar.tistory.com/143
27. SSH KEY-PAIR 개념(비대칭 키 인증 방식) - 현실을살아웅 - 티스토리, https://alive-wong.tistory.com/9
28. 4.3 Git 서버 - SSH 공개키 만들기, https://git-scm.com/book/ko/v2/Git-%EC%84%9C%EB%B2%84-SSH-%EA%B3%B5%EA%B0%9C%ED%82%A4-%EB%A7%8C%EB%93%A4%EA%B8%B0
29. SSH 키 쌍을 만드는 자세한 단계 - Azure Virtual Machines - Microsoft Learn, https://learn.microsoft.com/ko-kr/azure/virtual-machines/linux/create-ssh-keys-detailed
30. 블로그 - SSH 공개키 인증을 사용하여 암호 없이 편리하게 … - CUBRID, https://www.cubrid.com/blog/3825015
31. Secure Shell (SSH) Tutorial - Technology Services Organization, https://support.cc.gatech.edu/support-tools/howto/secure-shell-ssh-tutorial
32. SSH 키, OpenSSH 키, 그리고 내 서버에 키를 사용해서 로그인하기 - Lael’s World, https://blog.lael.be/post/10999
33. SSH 키 vs 비밀번호 : r/linuxquestions - Reddit, https://www.reddit.com/r/linuxquestions/comments/ehapud/ssh_keys_vs_password/?tl=ko
34. SSH(보안)에 대한 최종 가이드: 작동 방식 및 필수 요소 | 레노버 코리아 - Lenovo, https://www.lenovo.com/kr/ko/glossary/ssh/
35. [System Hardening] SSH 서비스 보안 강화하기: 안전한 원격 접속을 위한 가이드 - velog, https://velog.io/@gun_123/System-Hardening-SSH-%EC%84%9C%EB%B9%84%EC%8A%A4-%EB%B3%B4%EC%95%88-%EA%B0%95%ED%99%94%ED%95%98%EA%B8%B0-%EC%95%88%EC%A0%84%ED%95%9C-%EC%9B%90%EA%B2%A9-%EC%A0%91%EC%86%8D%EC%9D%84-%EC%9C%84%ED%95%9C-%EA%B0%80%EC%9D%B4%EB%93%9C
36. Telnet과 SSH의 차이 - Soohyun’s Blog - 티스토리, https://gmj-93.tistory.com/1
37. SSH & SCP & SFTP - Developing Myself Everyday - 티스토리, https://everyday-develop-myself.tistory.com/123
38. 리눅스 ssh 명령어 사용법 ( 원격 접속 프로토콜/centos7 ) - 롯사 by IT feedback, https://wlsvud84.tistory.com/entry/%EB%A6%AC%EB%88%85%EC%8A%A4-ssh-%EB%AA%85%EB%A0%B9%EC%96%B4-%EC%82%AC%EC%9A%A9%EB%B2%95-%EC%9B%90%EA%B2%A9-%EC%A0%91%EC%86%8D-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9Ccentos7
39. [네트워크] SSH 와 SFTP (feat. SCP vs SFTP) - 기록기록 - 티스토리, https://parkadd.tistory.com/129
40. Using PSFTP to transfer files securely - PuTTY - Documentation & Help, https://documentation.help/putty/psftp.html
41. SCP 리눅스 명령 - 원격에서 로컬로 SSH 파일을 전송하는 방법 - freeCodeCamp, https://www.freecodecamp.org/korean/news/scp-rinugseu-myeongryeong-weongyeogeseo-rokeolro-ssh-paileul-jeonsonghaneun-bangbeob/
42. SCP & SSH by Windows 10 PowerShell CLI Command Line Interface - CCI Technology Services And Support Site, https://support.cci.drexel.edu/cci-virtual-lab-resources/tux/scp-or-ssh-or-sftp-gui-or-cli/scp-windows-10-powershell-cli-command-line-interface/
43. Transferring Files with SSH - Scripting OS X, https://scriptingosx.com/2017/07/transferring-files-with-ssh/
44. SFTP | IT-Operations - Cloud 업무 자세히 보기, https://op.skill.or.kr/wiki/wiki/sftp
45. How to use the command line SSH and SFTP clients - FSU Computer Science, https://www.cs.fsu.edu/~myers/howto/commandLineSSH.html
46. How To Use SFTP to Securely Transfer Files with a Remote Server | DigitalOcean, https://www.digitalocean.com/community/tutorials/how-to-use-sftp-to-securely-transfer-files-with-a-remote-server
47. ssh 터널링 예제 - LOCKED, https://locked.com.pl/ssh-%ED%84%B0%EB%84%90%EB%A7%81-%EC%98%88%EC%A0%9C/
48. SSH Port Forwarding & Tunneling - 레드팀 플레이북, https://www.xn–hy1b43d247a.com/lateral-movement/ssh-tunnel
49. [Linux] ssh 터널링(ssh port forwarding) - Local / Remote / Dynamic …, https://hbase.tistory.com/328
50. [Network] Proxy 활용 - SSH 터널링 - Eunbig - 티스토리, https://eunbig48.tistory.com/8
51. SSH 로컬 포트 포워딩 (SSH 터널링) - 지식은 나눌 때 더 강해진다 - 티스토리, https://deep-jin.tistory.com/entry/SSH-%EB%A1%9C%EC%BB%AC-%ED%8F%AC%ED%8A%B8-%ED%8F%AC%EC%9B%8C%EB%94%A9-SSH-%ED%84%B0%EB%84%90%EB%A7%81
52. SSH 터널링 및 포트 포워딩 시각 가이드 (2023) - GeekNews, https://news.hada.io/topic?id=16859
53. Copying a local file from Mac to an ssh session in terminal [closed] - Stack Overflow, https://stackoverflow.com/questions/39457759/copying-a-local-file-from-mac-to-an-ssh-session-in-terminal
54. SSH SCP Local file to Remote in Terminal Mac Os X - Stack Overflow, https://stackoverflow.com/questions/11822192/ssh-scp-local-file-to-remote-in-terminal-mac-os-x
55. Get started with OpenSSH Server for Windows - Microsoft Learn, https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse
56. Copying a local file from Windows to a remote server using scp [closed] - Stack Overflow, https://stackoverflow.com/questions/8975798/copying-a-local-file-from-windows-to-a-remote-server-using-scp
57. Transfer File SFTP - Microsoft Q&A, https://learn.microsoft.com/en-us/answers/questions/969674/transfer-file-sftp
58. How to Use SFTP in PowerShell with Posh-SSH - NAKIVO, https://www.nakivo.com/blog/how-to-build-powershell-tools-to-setup-sftp/
59. Working with secure FTP in PowerShell | Chad’s Blog, https://chadbaldwin.net/2021/11/01/sftp-in-powershell.html
60. SSH File Transfer with PuTTY - HostKnox, https://www.hostknox.com/tutorials/ssh/putty/file-transfer
61. Chapter 6: Using PSFTP to transfer files securely, https://the.earth.li/~sgtatham/putty/0.52/htmldoc/Chapter6.html
62. PSFTP Download, Installation and Usage Guide - PuTTYgen, https://puttygen.com/psftp
63. Using PSFTP to transfer files securely, http://coast.cs.purdue.edu/pub/tools/windows/netutils/putty/devel/htmldoc/Chapter6.html
64. How to upload file to PuTTY using PSFTP? - Super User, https://superuser.com/questions/1830950/how-to-upload-file-to-putty-using-psftp
65. 1.6. OpenSSH의 보안 강화 | 네트워크 보안 | Red Hat Enterprise Linux | 9, https://docs.redhat.com/ko/documentation/red_hat_enterprise_linux/9/html/securing_networks/making-openssh-more-secure_assembly_using-secure-communications-between-two-systems-with-openssh
66. 공개 SSH 서버의 보안을 가장 잘 강화하는 방법은 무엇일까요? : r/linux4noobs - Reddit, https://www.reddit.com/r/linux4noobs/comments/4mb20b/how_to_best_tighten_security_on_a_publicfacing/?tl=ko
67. 보안취약점 점검 가이드 및 조치 방법 - JW’s Tech Blog, https://prolinux.kr/13
68. 4.3.11.3. SSH 보안의 다른 방법 | 보안 가이드 | Red Hat Enterprise Linux | 7, https://docs.redhat.com/ko/documentation/red_hat_enterprise_linux/7/html/security_guide/securing_ssh-other_ways
69. Linux ssh 보안 설정 - 하늘정원 - 티스토리, https://minsoo3380.tistory.com/7
70. CentOS7 ssh보안설정 및 fail2ban 설정하기 - storm - 티스토리, https://nitocin.tistory.com/entry/fail2ban-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0
71. 리눅스 SSH 보안 및 sudo 설정 - WEBDIR - 티스토리, https://webdir.tistory.com/123
72. Fail2ban으로 SSH 보안 강화하기 - NY64의 무한삽질 블로그, https://blog.ny64.kr/posts/setting-up-fail2ban-on-raspberry-pi/
73. ssh 무차별 공격에 대비한 fail2ban 사용법 > OS | 서버호스팅 전문 기업 - 비아웹 기술블로그, https://tech.viaweb.co.kr/OS/133
74. fail2ban 설치 - 상구리의 기술 블로그, https://www.skyer9.pe.kr/wordpress/?p=3074